Dynamically-Updatable Deep Transactional Monitoring Systems and Methods

ABSTRACT

Provided herein are system, method and computer program products for providing dynamically-updatable deep transactional monitoring of running applications in real-time. A method for monitoring a target software application operates by injecting a software engine into a new thread within a target process of the target software application. The method then retrieves a monitoring script and initiates execution of the monitoring script within the software engine. The monitoring script determining the address functions and calls to the functions and inserts a trampoline call within the one or more functions. The trampoline saves the execution state of the target process and calls a corresponding monitoring function that to retrieves data associated with the target process. The method then restoring the execution state of the target process and resumes execution of the target function.

This application claims priority from U.S. Provisional Application62/656,308 filed on 11 Apr. 2018, which is hereby incorporated byreference in its entirety for all purposes.

BACKGROUND Technical Field

Embodiments generally relate to software monitoring, and in particularto systems and methods for performing deep transactional monitoring ofrunning applications in production usage.

Background

Software application performance management (APM) is the monitoring andmanagement of the performance and availability of software applications.APM is a crucial part of ensuring software reliability, allowing fastdiagnosis and recovery from runtime failures. APM software can bedesigned to detect and diagnose performance problems in a targetapplication, with the goal of maintaining an expected level of serviceby the application.

Any set of performance metrics can be monitored by an APM system. Onecommon set of metrics describes the performance experienced by end usersof an application, for example, average response times under peak load.Another common set of metrics measures the computational resources usedby the application for a particular load, for example, CPU and memoryusage. Computational resource measurements can help discover performancebottlenecks, detect changes in performance, and predict future changesin application performance.

One variant of APM is known as real user monitoring (RUM), whichinvolves passively recording user interaction with an application orclient interacting with a server or cloud-based application. Monitoringactual user interaction with a website or an application is important tooperators to determine if users are being served quickly and withouterrors and, if not, which part of a business process is failing. Realuser monitoring data is used to determine the actual service-levelquality and transactional integrity delivered to end-users and to detecterrors or slowdowns on application. The data may also be used todetermine if changes that are promulgated to application have theintended effect or cause errors.

One variant of RUM is known as business transaction monitoring (BTM),which provides tools for tracking the flow of transactions across ITinfrastructure and code-level drill-down into defined portions of thetransactions, in addition to detection, alerting, and correction ofunexpected changes in business or technical conditions. BTM providesvisibility into the flow of transactions across infrastructure tiers,including a dynamic mapping of the application topology and deepcode-level drill-down in defined portions of the transactions. BTM mayallow searching for transactions based on context and content—forinstance, user performing the transaction, time and code context ofexecution of functions, web requests, or web services, input argumentsand return values, and system component executing thetransaction,—providing a way to isolate causes for issues such asapplication exceptions, stalled transactions, and lower-level issuessuch as incorrect data values.

In general, performing APM can be a complicated process that involvesmany technical challenges. Among them, APM has a performance cost, whichcan range from minor and negligible to extremely high impact and onlysuitable for development and non-production environments. Certainmethods involve modifying the target application source code andrecompiling, but this generally requires suspending and restarting theapplication. Some APM software may also need access to system resourcesthat may be protected from reading or writing by security measures, forexample, requiring administrator/root access. Other applications mayblock third-party library preloads, further complicating the options toaccess application data for methods that require modification of systemlibraries or system preload directives. Many known methods only work oninterpreted processes (e.g., coded in Java, Node.js, etc.) but will notwork on compiled native processes (e.g., coded in C, C++, etc.). Othersdepend on frameworks such as .NET or J2EE or profiling APIs such asprovided for Java and .NET.

BRIEF DESCRIPTION OF DRAWINGS

The accompanying drawings are incorporated herein and form a part of thespecification.

FIG. 1 illustrates a target application monitoring environment,according to an example embodiment.

FIG. 2 shows a diagram describing the flow of data in monitoringenvironment, according to an example embodiment.

FIG. 3A shows a set of instructions illustrating how a thread may createa trampoline to a monitoring function, according to an exampleembodiment.

FIG. 3B shows a set of instructions illustrating the stalker approachadds instrumentation to target functions, according to an exampleembodiment.

FIG. 4 is an example computer system useful for implementing variousembodiments.

DETAILED DESCRIPTION

Provided herein are system, method and/or computer program productembodiments, and/or combinations and sub-combinations thereof, forproviding dynamically-updatable deep transactional monitoring of runningapplications in real-time.

FIG. 1 illustrates a target application monitoring environment 100,according to an example embodiment. A target application 112 runs on asoftware environment (e.g., an operating system) running on a targetserver 110. The target application may be any application, such as, byway of example, back end application providing services over a network.In particular embodiments, target application 112 is an applicationdeveloped in native compiled code (e.g., C/C++). Target application mayalso be a hosted application or a SaaS application running on a hostprovider. One or more agents 114 also runs on target server 110, and inparticular embodiments, an agent 114 follows an injection approach whereit runs as a separate process within target server 110. In anotherembodiment, the agent 114 follows an embedded approach where it runsinside one or more target processes 113. Agent 114 is configured tocollect data from one or more target processes 113 in real-time andtransmit the data to monitoring applications. Target application mayhave one or more agents performing application monitoring.

Agent 114 communicates with a collector server 120 via a network 150.Collector server 120 may run one or more monitoring processes 122 andstore one or more monitoring scripts 124. Processes 122 in collectorserver 120 may be configured to receive monitoring data from agent 114and control the agent's behavior. For example, agent 114 may receiveinstructions on what data to collect from target process 113 and howoften to collect it.

In particular embodiments following an injection approach, agent 114creates a new monitoring thread 115 within one or more target processes113. In an example, agent 114 may inject a Javascript engine (e.g, aGoogle® V8 engine or a Duktape engine, for example) into the new thread115. Monitoring thread 115 may run one or more of the monitoring scripts124 provided by agent 114, in accordance with the instructions receivedfrom, for example, monitoring processes 122. In an example, monitoringscripts 124 may be Javascript scripts that are interpreted and executedby the injected Javascript engine. Thread 115 may receive monitoringscripts 124 stored in collector server 120 at runtime, as well asupdates and modifications to the scripts, from agent 114 whichcommunicates with collector processes 122 via a suitable communicationschannel (e.g., SSH tunnel). In this manner, monitoring processes 122 mayload monitoring scripts 124 into thread 115 by communicating with agent114 via the communications channel. New or updated monitoring scripts124 may be loaded in real-time without the need to restart the targetprocesses

Collector server 120 may in turn communicate with a monitoring server130 via network 150. Monitoring server may include a controller 132,database 134, and monitoring portal 136. Controller 132 communicateswith collector server 120 and provides instructions for configuring themonitoring processes 122 and agents 114 and/or updating the monitoringscripts 124 that will be run inside the process(es) thread(s). Database134 may receive and store data collected by agent 114 via the monitoringprocesses 122 running on collector server 120. Monitoring portal 136 mayretrieve the data from database 134 and prepare it for presentation atan end-user device 140. In particular embodiments, database 134 may behosted in monitoring server 130, in a separate system external tomonitoring server 130, or any combination of both. Monitoring portal 136may generate any suitable application performance monitoring system userinterface for display in an end-user device 140. The user interface mayprovide for controlling data collected, visualizing data, receivingevents, and sending alerts, among other functions.

Network 150 may be any communications network or combination of networkssuitable for transmitting data between computing devices, such as, byway of example, a Local Area Network (LAN), a Wide Area Network (WAN),Metropolitan Area Network (MAN), Personal Area Network (PAN), theInternet, wireless networks, satellite networks, overlay networks, orany combination thereof. While some embodiments described herein aredescribed within the context of a networked system, it should beunderstood this disclosure contemplates the any combination of networkedor non-networked system. For example, all modules, servers, andprocesses described herein may run in a single computing system.

End-user device 140 may be any computing device with software suitablefor user interface interaction, such as, by way of example, a personalcomputer, mobile computer, laptop computer, mobile phone, smartphone,personal digital assistant, tablet computer, etc. The user interface maybe displayed in any suitable software, such as, by way of example, astandalone application, a web interface, a console interface, etc.Servers 110, 120, and 130 may be any computing device or combination ofdevices suitable to provide server services, such as, by way of example,server computers, personal computers, database systems, storage areanetworks, web servers, application servers, etc., or any combinationthereof.

FIG. 2 shows a diagram describing the flow of data in monitoringenvironment 100, according to an example embodiment. In particularembodiments, the agent 114 attaches to target process 113 and uses asoftware engine started in thread 115 to run monitoring script(s) 124.The software engine is a runnable component capable of interpreting themonitoring APIs. The engine provides native access to low-level computerarchitecture. The monitoring scripts may be in low-level languages suchas C/C++ or higher level languages (such as Javascript), and because themonitoring scripts are running in a thread inside the target process,the scripts have access to low-level computer constructs, such as memorylocations, execution stack, registers, threads, and to hook functionsand call native application and system functions. As an example, theagent may create a monitoring thread 115 to be run within target process113 that injects a Javascript engine (a Google® V8 engine or a Duktapeengine, for example) into the thread. In this example, monitoring thread115 may run Javascript monitoring scripts 124 that are interpreted andexecuted by the Javascript engine. The monitoring scripts 124 may inthis manner have full access to inspect memory, threads, and registers,and to hook functions and call native application and system functionsfrom inside process 113. By attaching to the process 113 and starting athread (or, in another embodiment using an embedded approach, beingpreloaded into the application), the thread has access to createtrampolines, as described below.

Agent 114 may use various techniques to obtain transactional monitoringinformation from target processes 113. In particular embodiments, agent114 uses an interception approach. Monitoring scripts 124 running inthread 115 may reference one or more functions used by target process113. Agent 114 may receive instructions specifying which monitoringscripts 124 to be loaded. The monitoring scripts 124 define whichfunctions and what data from the functions to monitor. Agent 114 and/orthread 115 obtain the memory address of the functions to be monitored.Thread 115 then generates a trampoline for calling a monitoringinterceptor code (specified for that function within the scripts 124) atcertain points in the function's execution by substituting (for example)the first or last instruction in the targeted function for aninstruction that calls the monitoring interceptor code within amonitoring script 124. In this embodiment, the interceptor code updatesstacks and registers to pre-interception status prior to returningexecution back to the target function.

FIG. 3A shows a set of instructions illustrating how a thread 115 maycreate a trampoline to a monitoring function, according to an exampleembodiment. A target process 113 may at some point in execution call afunction called “decrypt_frame.” Monitoring scripts 124 specifying thisfunction may have been inserted into thread 115 by agent 114 perinstructions sent from monitoring collector 120. Thread 115 may thussubstitute the first instruction in the function “decrypt_ frame” for atrampoline instruction, as shown by instruction “jmp trampoline,” whichtransfers execution to the block labeled “trampoline.” Thus, each timethe function “decrypt_frame” is called, the execution runs into thetrampoline. The trampoline function may then save the state of the stackand registers and call monitoring interceptor code within the monitoringscript 124 (e.g., Javascript script) that may perform the desiredmonitoring for the monitoring system. For example, the script 124 mayrecord the time the “decrypt_frame” instruction was called, the value ofinput arguments received by the function, and any other data relevant tomonitor the state or performance of the application. The information tobe monitored may ultimately be configured by the rest of the monitoringsystem based on end-user instructions. Once the monitoring data has beenstored or sent, the trampoline restores the registers to the originalvalues before the trampoline call. Thread 115 may insert a trampoline inthis manner at any point in execution, not just at the beginning of afunction. As an example, thread 115 may replace the return instructionof a function with trampoline that may collect, for example, the timethe function ended and the return values. In this manner, thread 115 maycollect the execution time of a function based on the time the functionstarted and ended, and thus allow monitors to assess the performance ofthe function and process.

Agent 114 may communicate via a bi-directional communication channelswith monitor communication processes 122 and monitoring scripts 124running on threads 115. As an example, the communication channels may bean SSH tunnels, thus maintaining security of sensitive targetapplication data. Agent 114 may transmit the data collected bymonitoring scripts 124, and receive configuration and instructions forwhat functions to monitor, what data to collect, and at what points inthe functions to collect the data.

In particular embodiments, monitoring scripts 124 may directly findfunction pointers to a specific application functions of target process113 and execute them. The scripts may retrieve data or results from thefunction's execution and store and/or transmit the data, e.g., formonitoring purposes. As an example, agent 114 may communicate thefunction execution data to collector 120.

The interception approach has numerous benefits. For example, it doesnot require access to the target application source code norroot/administrator level permissions. The approach allows monitoring tobe enabled/disabled and modified in real-time without the need torestart the application. As implemented/optimized, it has minimalperformance or system impact, and does not require source codeinstrumentation, modification, or compilation. Furthermore, thisapproach can be used on applications that block third-party librarypreloads and/or do not utilize shared resources, and thus allowstransactional monitoring of these applications. It can monitor bothapplication and system functions as well as both static or non-staticfunctions. Finally, this approach works for compiled native processes(coded in C, C++, etc.) as well as interpreted processes (coded in Java,Node.js, etc.)

In particular embodiments, agent 114 uses an embedded approach formonitoring, as mentioned earlier. In this scenario, the target process112 is modified by embedding a library into the code through suitablemeans, such as, for example, source code modification, patching, orpreloading. In particular embodiments, agent 114 is then loaded into andrun in a separate new thread within target process 113, as opposed to anew process. In other embodiments, agent 114 may be embedded into theprocess. This loading is performed after the dynamic linker executes itsconstructor. The agent 114 then creates the thread 115, which thendirectly communicates with monitoring communication processes incollector 120, for example, via an SSH tunnel. The embedded approachalso provides the option of storing the monitoring scripts 124 directlyon the target system (as shown by dashed box 124 in FIG. 1) forautonomous application by the embedded agent. Modifications to thesestored monitoring scripts 124 can be applied in real-time to runningprocesses. The embedded approach may be useful in scenarios when accessto source code, patch, or pre-loading is available.

In particular embodiments, agent 114 uses a stalker approach formonitoring. The stalker approach may be useful in scenarios where thetarget application has strict in-app self-checking and the previouslydescribed approaches may not work. In the stalker approach, an agentintercepts function calls in target process 113 and splits them intobasic blocks. A basic block is a straight-line code sequence with nobranches-in except to the entry and no branches-out except at the exit.This restricted form makes a basic block highly amenable to analysis.Compilers usually decompose programs into their basic blocks as a firststep in the analysis process.

FIG. 3B shows a set of instructions illustrating the stalker approachadds instrumentation to target functions, according to an exampleembodiment. Each instruction is wrapped in instrumentation and a callback to stalker monitoring functions is made at every block transition.Stalker agent 114 incrementally rewrites basic blocks, addinginstrumentation and the call back into monitoring functions at everybasic block transition. By using this approach there is no stackmodification, no register modification, and can be used in cases wherethe application code is self-modifying and self-checking (e.g., withchecksums). The system can specify which functions are followed (asopposed to whole-program dynamic binary instrumentation alternatives)and can also add custom updates and synchronous callbacks through theuse of the software engine (e.g., Javascript engine).

The stalker approach has numerous benefits. As with the interceptionapproach, it does not require access to the target application sourcecode nor root/administrator level permissions. The approach allowsmonitoring to be enabled/disabled and modified in real-time without theneed to restart the application. As implemented/optimized, it hasminimal performance or system impact, and does not require source codeinstrumentation, modification, or compilation. Furthermore, thisapproach can be used on applications that block third-party librarypreloads and/or do not utilize shared resources, and thus allowstransactional monitoring of these applications. It can monitor bothapplication and system functions as well as both static or non-staticfunctions. Finally, this approach works for compiled native processes(coded in C, C++, etc.) as well as interpreted processes (coded in Java,Node.js, etc.)

FIG. 4 illustrates an example computer system 400. In particularembodiments, one or more computer systems 400 perform one or more stepsof one or more methods described or illustrated herein. In particularembodiments, one or more computer systems 400 provide functionalitydescribed or illustrated herein. In particular embodiments, softwarerunning on one or more computer systems 400 performs one or more stepsof one or more methods described or illustrated herein or providesfunctionality described or illustrated herein. Particular embodimentsinclude one or more portions of one or more computer systems 400.Herein, reference to a computer system may encompass a computing device,and vice versa, where appropriate. Moreover, reference to a computersystem may encompass one or more computer systems, where appropriate.

This disclosure contemplates any suitable number of computer systems400. This disclosure contemplates computer system 400 taking anysuitable physical form. As example, computer system 400 may be anembedded computer system, a desktop computer system, a laptop ornotebook computer system, a mainframe, a mobile telephone, a personaldigital assistant (PDA), a server, a tablet computer system, or acombination of two or more of these. Where appropriate, computer system400 may include one or more computer systems 400; be unitary ordistributed; span multiple locations; span multiple machines; spanmultiple data centers; or reside in a cloud, which may include one ormore cloud components in one or more networks. Where appropriate, one ormore computer systems 400 may perform without substantial spatial ortemporal limitation one or more steps of one or more methods describedor illustrated herein. As an example, one or more computer systems 400may perform in real time or in batch mode one or more steps of one ormore methods described or illustrated herein. One or more computersystems 400 may perform at different times or at different locations oneor more steps of one or more methods described or illustrated herein,where appropriate.

In particular embodiments, computer system 400 includes a processor 402,memory 404, storage 406, an input/output (I/O) interface 408, acommunication interface 410, and a bus 412. Although this disclosuredescribes and illustrates a particular computer system having aparticular number of particular components in a particular arrangement,this disclosure contemplates any suitable computer system having anysuitable number of any suitable components in any suitable arrangement.

In particular embodiments, processor 402 includes hardware for executinginstructions, such as those making up a computer program. As an example,to execute instructions, processor 402 may retrieve (or fetch) theinstructions from an internal register, an internal cache, memory 404,or storage 406; decode and execute them; and then write one or moreresults to an internal register, an internal cache, memory 404, orstorage 406. In particular embodiments, processor 402 may include one ormore internal caches for data, instructions, or addresses. Thisdisclosure contemplates processor 402 including any suitable number ofany suitable internal caches, where appropriate. In particularembodiments, processor 402 may include one or more internal registersfor data, instructions, or addresses. This disclosure contemplatesprocessor 402 including any suitable number of any suitable internalregisters, where appropriate. Where appropriate, processor 402 mayinclude one or more arithmetic logic units (ALUs); be a multi-coreprocessor; or include one or more processors 402. Although thisdisclosure describes and illustrates a particular processor, thisdisclosure contemplates any suitable processor.

In particular embodiments, memory 404 includes main memory for storinginstructions for processor 402 to execute or data for processor 402 tooperate on. As an example, computer system 400 may load instructionsfrom storage 406 or another source (such as, for example, anothercomputer system 400) to memory 404. Processor 402 may then load theinstructions from memory 404, execute the instructions, write one ormore results to memory 404. In particular embodiments, memory 404includes volatile memory, such as random access memory (RAM).

In particular embodiments, storage 406 includes mass storage for data orinstructions. As an example, storage 406 may include a hard disk drive(HDD), a floppy disk drive, flash memory, an optical disc, amagneto-optical disc, magnetic tape, or a Universal Serial Bus (USB)drive or a combination of two or more of these. Storage 406 may includeremovable or non-removable (or fixed) media, where appropriate. Storage406 may be internal or external to computer system 400, whereappropriate. In particular embodiments, storage 406 is non-volatile,solid-state memory. In particular embodiments, storage 406 includesread-only memory (ROM). Where appropriate, this ROM may bemask-programmed ROM, programmable ROM (PROM), erasable PROM (EPROM),electrically erasable PROM (EEPROM), electrically alterable ROM (EAROM),or flash memory or a combination of two or more of these.

In particular embodiments, I/O interface 408 includes hardware,software, or both, providing one or more interfaces for communicationbetween computer system 400 and one or more I/O devices. Computer system400 may include one or more of these I/O devices, where appropriate. Oneor more of these I/O devices may enable communication between a personand computer system 400. As an example, an I/O device may include akeyboard, keypad, microphone, monitor, mouse, printer, scanner, speaker,still camera, stylus, tablet, touch screen, trackball, video camera,another suitable I/O device or a combination of two or more of these. An

In particular embodiments, communication interface 410 includeshardware, software, or both providing one or more interfaces forcommunication (such as, for example, packet-based communication) betweencomputer system 400 and one or more other computer systems 400 or one ormore networks. As an example, communication interface 410 may include anetwork interface controller (NIC) or network adapter for communicatingwith an Ethernet or other wire-based network or a wireless NIC (WNIC) orwireless adapter for communicating with a wireless network, such as aWI-FI network. This disclosure contemplates any suitable network and anysuitable communication interface 410 for it. As an example, computersystem 400 may communicate with an ad hoc network, a personal areanetwork (PAN), a local area network (LAN), a wide area network (WAN), ametropolitan area network (MAN), or one or more portions of the Internetor a combination of two or more of these. One or more portions of one ormore of these networks may be wired or wireless.

In particular embodiments, bus 412 includes hardware, software, or bothcoupling components of computer system 400 to each other. As an example,bus 412 may include an Accelerated Graphics Port (AGP) or other graphicsbus, an Enhanced Industry Standard Architecture (EISA) bus, a front-sidebus (FSB), a HYPERTRANSPORT (HT) interconnect, an Industry StandardArchitecture (ISA) bus, an INFINIBAND interconnect, a low-pin-count(LPC) bus, a memory bus, a Micro Channel Architecture (MCA) bus, aPeripheral Component Interconnect (PCI) bus, a PCI-Express (PCIe) bus, aserial advanced technology attachment (SATA) bus, a Video ElectronicsStandards Association local (VLB) bus, or another suitable bus or acombination of two or more of these. Bus 412 may include one or morebuses 412, where appropriate. Although this disclosure describes andillustrates a particular bus, this disclosure contemplates any suitablebus or interconnect.

Herein, a computer-readable non-transitory storage medium or media mayinclude one or more semiconductor-based or other integrated circuits(ICs) (such, as for example, field-programmable gate arrays (FPGAs) orapplication-specific ICs (ASICs)), hard disk drives (HDDs), hybrid harddrives (HHDs), optical discs, optical disc drives (ODDs),magneto-optical discs, magneto-optical drives, floppy diskettes, floppydisk drives (FDDs), magnetic tapes, solid-state drives (SSDs),RAM-drives, SECURE DIGITAL cards or drives, any other suitablecomputer-readable non-transitory storage media, or any suitablecombination of two or more of these, where appropriate. Acomputer-readable non-transitory storage medium may be volatile,non-volatile, or a combination of volatile and non-volatile, whereappropriate.

In particular embodiments, computer system 400 may be configured to runan operating system software. An operating system manages computersystem hardware and software resources and provides common services forcomputer programs. Modern operating systems are multi-tasking operatingsystems, which allow more than one program to run concurrently. Theoperating system may use time-sharing of available processor time bydividing the time between multiple processes. A process is an instanceof a computer program that is being executed, containing the programcode and its current activity. These processes are each interruptedrepeatedly in time slices by a task-scheduling subsystem of theoperating system. In particular embodiments, the operating system alsoallows the implementation of multiple threads of execution runningwithin a process. A thread of execution (or simply a thread) is asmaller sequence of programmed instructions that is managed by ascheduling subsystem, and forms a component of a process. In general,multiple threads can exist within one process and share resources suchas memory, while different processes may not share these resources. Inparticular, the threads of a process may share its executable code andthe values of its variables at any given time.

It is to be appreciated that the Detailed Description section, and notthe Summary and Abstract sections (if any), is intended to be used tointerpret the claims. The Summary and Abstract sections (if any) may setforth one or more but not all exemplary embodiments of the invention ascontemplated by the inventor(s), and thus, are not intended to limit theinvention or the appended claims in any way.

While the invention has been described herein with reference toexemplary embodiments for exemplary fields and applications, it shouldbe understood that the invention is not limited thereto. Otherembodiments and modifications thereto are possible, and are within thescope and spirit of the invention. For example, and without limiting thegenerality of this paragraph, embodiments are not limited to thesoftware, hardware, firmware, and/or entities illustrated in the figuresand/or described herein. Further, embodiments (whether or not explicitlydescribed herein) have significant utility to fields and applicationsbeyond the examples described herein.

Embodiments have been described herein with the aid of functionalbuilding blocks illustrating the implementation of specified functionsand relationships thereof. The boundaries of these functional buildingblocks have been arbitrarily defined herein for the convenience of thedescription. Alternate boundaries can be defined as long as thespecified functions and relationships (or equivalents thereof) areappropriately performed. Also, alternative embodiments may performfunctional blocks, steps, operations, methods, etc. using orderingsdifferent than those described herein.

References herein to “one embodiment,” “an embodiment,” “an exampleembodiment,” or similar phrases, indicate that the embodiment describedmay include a particular feature, structure, or characteristic, butevery embodiment may not necessarily include the particular feature,structure, or characteristic. Moreover, such phrases are not necessarilyreferring to the same embodiment. Further, when a particular feature,structure, or characteristic is described in connection with anembodiment, it would be within the knowledge of persons skilled in therelevant art(s) to incorporate such feature, structure, orcharacteristic into other embodiments whether or not explicitlymentioned or described herein.

The breadth and scope of the invention should not be limited by any ofthe above-described exemplary embodiments, but should be defined only inaccordance with the following claims and their equivalents.

What is claimed is:
 1. A computer-implemented method for monitoring atarget software application, the method comprising: injecting a softwareengine into a new thread within a target process of the target softwareapplication; retrieving a monitoring script; and initiating execution ofthe monitoring script within the software engine, the monitoring scriptconfigured to perform steps comprising: determining the address of oneor more functions and one or more calls to the one or more functions,inserting a trampoline call within the one or more functions, thetrampoline saving the execution state of the target process and callinga corresponding monitoring function, wherein the monitoring function isconfigured to retrieve one or more data values associated with thetarget process, restoring the execution state of the target process, andresuming execution of the target function.
 2. The method of claim 1,wherein the injecting, receiving, and initiating execution steps areperformed by a separate agent process within an environment of thetarget software.
 3. The method of claim 1, wherein the injecting,receiving, and initiating execution steps are performed by an agentrunning within the target process.
 4. The method of claim 1, the methodfurther comprising: injecting the software engine into a second newthread within a second target process of the target softwareapplication; and initiating execution of the same or a differentmonitoring script within the software engine in the second new thread.5. The method of claim 1, further comprising: receiving a secondmonitoring script through the communications channel; and initiatingexecution of the second monitoring script within the software engine. 6.The method of claim 1, further comprising: determining whether a newmonitoring script is available or an existing monitoring script has beenmodified; retrieving the new or modified monitoring script; andinitiating execution of the new or modified monitoring script.
 7. Themethod of claim 1, wherein the software engine accesses or modifiescomputer memory locations, execution stack, registers, and threadswithin the target process.
 8. The method of claim 1, wherein theretrieving the monitoring script comprises receiving the monitoringscript through a communications channel.
 9. The method of claim 8,wherein the communications channel comprises at least one of a secureshell (SSH) tunnel connection or a Transport Control Processes (TCP)connection.
 10. The method of claim 1, wherein the software enginecomprises at least one of a Google V8 engine or a Duktape engine. 11.The method of claim 1, wherein the monitoring script is configured tofurther perform the steps of: finding a target application function inthe target process; initiating execution of the target applicationfunction; and retrieving data resulting from the execution of thefunction.
 12. The method of claim 1, wherein the monitoring script is aJavascript script.
 13. The method of claim 1, wherein the at least oneor more data values comprises at least one of a value of a process,application, or function variable, a value of a memory location, afunction return value or input value, or a timestamp.
 14. Acomputer-implemented method for monitoring a target softwareapplication, the method comprising: injecting a software engine into anew thread within a target process of the target software application;retrieving a monitoring script; initiating execution of the monitoringscript within the software engine, the monitoring script configured toperform steps comprising: intercepting a function call of the targetprocess, splitting a plurality of instructions of the function into aplurality of blocks, wrapping each of the instructions ininstrumentation, performing a call back to a monitoring script at theend of each of the plurality of blocks, wherein the monitoring script isconfigured to store one or more data values associated with the targetprocess.
 15. The method of claim 12, wherein each of the plurality ofblocks comprises a sequence of instructions with no branches-in exceptto the entry of the block and no branches-out except at the exit of theblock.
 16. The method of claim 12, the method further comprising:injecting the software engine into a second new thread within a secondtarget process of the target software application; and initiatingexecution of the monitoring script within the software engine in thesecond new thread.
 17. The method of claim 12, further comprising:receiving a second monitoring script through the communications channel;and initiating execution of the second monitoring script within thesoftware engine.
 18. A tangible non-transitory computer-readable mediumhaving instructions stored thereon that, when executed by at least onecomputing device, causes the at least one computing device to performoperations comprising: injecting a software engine into a new threadwithin a target process of the target software application; receiving amonitoring script; and initiating execution of the monitoring scriptwithin the software engine, the monitoring script configured to performsteps comprising: determining the address of one or more functions andone or more calls to the one or more functions, inserting a trampolinecall within the one or more functions, the trampoline saving theexecution state of the target process and calling a correspondingmonitoring function, wherein the monitoring function is configured toretrieve one or more data values associated with the target process,restoring the execution state of the target process, and resumingexecution of the target function.
 19. A system, comprising: a memory;and at least one processor coupled to the memory and configured to:inject a software engine into a new thread within a target process ofthe target software application; receive a monitoring script; andinitiate execution of the monitoring script within the software engine,the monitoring script configured to perform steps comprising:determining the address of one or more functions and one or more callsto the one or more functions, inserting a trampoline call within the oneor more functions, the trampoline saving the execution state of thetarget process and calling a corresponding monitoring function, whereinthe monitoring function is configured to retrieve one or more datavalues associated with the target process, restoring the execution stateof the target process, and resuming execution of the target function.